home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000061_icon-group-sender _Wed Apr 28 22:07:34 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 5 May 1993 05:23:54 MST
  2. Date: 28 Apr 93 22:07:34 GMT
  3. From: pipex!warwick!qmw-dcs!qmw!demon!cix.compulink.co.uk!pmoore@uunet.uu.net  (Paul Moore)
  4. Subject: Re: "Find that Niche!" contest?
  5. Message-Id: <memo.173077@cix.compulink.co.uk>
  6. Sender: icon-group-request@cs.arizona.edu
  7. To: icon-group@cs.arizona.edu
  8. Status: R
  9. Errors-To: icon-group-errors@cs.arizona.edu
  10.  
  11.  
  12.  
  13. Jan de Ruiter writes:
  14.  
  15.   > The unique thing of Icon (IMHO, of course) is that it
  16.   > reduces development time so drastically that it actually
  17.   > pays to use it, even when the performance is
  18.   > interpreter-like. 
  19.  
  20. Interestingly enough, this relates to my experiences. The important thing
  21. about Icon is that it is about string processing. Huge amounts of the time
  22. people spend using computers involves string processing, so any language
  23. which makes this easy, tends to win in the "quick program" department. (For
  24. bigger projects, other considerations come into play, such as ease of reuse,
  25. configuration management, etc)
  26.  
  27. Now, I have access to both perl and Icon. Both are good for quick string
  28. hacking programs. Perl is 100% interpreted, and so the cycle is "type the
  29. program in, run it, work out what went wrong, fix & rerun ...". With Icon,
  30. where there is a compile stage, the cycle, while similar, FEELS more like
  31. "write a program, test it, fix errors, and once working, run it for real".
  32. That is, perl programs tend to converge on the behaviour you want (and may
  33. never get there - you may stop when you have something "good enough"),
  34. whereas Icon programs are designed to do what you want, and debugged until
  35. they work.
  36.  
  37. This is more opinion/psychology than hard fact, but perhaps it explains why
  38. I use perl more than Icon - I think I can get away with a quick hack, until
  39. it is too late and I realise I should have designed more carefully from the
  40. start. On the other hand, it does mean that I tend to use Icon when I want
  41. something that *works*.
  42.  
  43. Not faults of the language(s), [of course, you can write well designed
  44. perl code - all I am saying is that *I* don't, often...] but definitely
  45. different "flavours" to them...
  46.  
  47. Just my penny worth,
  48.  
  49. Gustav (pmoore@cix.compulink.co.uk)
  50.